IBIS Macromodel Task Group Meeting date: 08 February 2022 Members (asterisk for those attending): Achronix Semiconductor: * Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Majid Ahadi Dolatsara Ming Yan * Radek Biernacki * Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: * Randy Wolff Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Hansel said he had a new question about the IR for statistical flow that we could discuss. ------------- Review of ARs: - Fangyi to review Walter's draft of BIRD 211.4. - Done. Fangyi had sent a new draft that included one correction. - Walter to send out a new draft of BIRD213.1 addressing Randy's comments. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 1st meeting. Randy moved to approve the minutes. Ambrish seconded the motion. There were no objections. ------------- New Discussion: BIRD211.4 draft 2, IBIS AMI Reference Flow Improvements: Arpad asked if we all agreed this was ready to send to the Open Forum, given that Fangyi had completed his review and sent draft 2 to the ATM list. Radek moved that draft 2 be submitted to the Open Forum as BIRD211.4. Walter seconded the motion. There were no objections. Arpad took an AR submit BIRD211.4 to the Open Forum. BIRD213.1 draft 11, PAMn: Walter shared draft 11. He said one question that had arisen was, "If a model supports PAM2, 3, and 4, then what should the model do with PAM_Thresholds and PAM_Offsets if the user selects PAM2?" These parameters would have to be provided as Usage Out to support PAM3 and PAM4, but what should the model do with them in PAM2? Walter suggested that the model should be expected to return a single-row table for each of the parameters, with the value of the row likely to be zero. He said this would be cleaner than adding language to the BIRD stating that the parameters were optional in the case of PAM2. Fangyi agreed that for the sake of consistency the model should return PAM_Offsets and PAM_Thresholds for any value of n. Walter said we probably expect the values to be zero in the case of PAM2, but allowing for non-zero values might turn out out to be useful in the future. Ambrish noted that he had always opposed requiring the model to return PAM_Thresholds. He said some models may return bad thresholds, and the tools will have to handle that scenario anyway. Walter said that in discussing this BIRD with model makers there had been universal agreement that if the model doesn't know its own thresholds its results are likely to be nonsense. Fangyi said that Type Integer should not be allowed for PAM_Thresholds. He said only Float should be allowed. Walter agreed and removed Integer. Fangyi and Arpad commented on the definition of "reference row" in the Usage Rules for PAM_Offsets. Fangyi said that for time-domain simulation we don't need any concept of a reference row at all. PAM_Offsets simply provides n-1 independent offsets to be applied to the single set of clock times returned in clock_times. Walter agreed that the reference row discussion could be removed for time-domain. Walter said that for statistical simulation you need to define the reference row since you don't have clock_times. If Rx_Decision_Time is provided, then that can be the starting point for the offsets. Fangyi agreed, and asked that we define the behavior with an equation. For example: If t0 is the Rx_Decision_Time, or the center of the nominal eye as computed by the EDA tool if Rx_Decision_Time is not provided, then the sampling time of the kth eye is t0 + kth row of PAM_Offsets. Note: this assumes PAM_Offsets already includes Rx_Recovery_Mean. Walter said he would add similar language to the BIRD. The group reviewed comments Arpad had submitted via email. In the text to be modified on page 228, Arpad questioned what was meant by "the electrical interface to either the driver or receiver is differential". The group agreed that this was not meant to imply that single-ended and differential could be mixed, and it should have said "both the driver and receiver". Fangyi and Walter said we aren't really talking about the physical/electrical interface. We are talking about the model interface. Walter said when AMI was originally introduced it only considered differential devices, and Fangyi said now with the DC_Offset parameter the input waveform to GetWave is differential even when modeling single-ended devices. Arpad said this sentence would need additional work. Fangyi suggested the entire sentence should simply be removed. It was not helpful, and everything it mentioned was already defined elsewhere. Walter agreed and removed the sentence entirely. Arpad said the first sentence of Usage Rules for Modulation_Levels: "It is declared as Type Integer." should be removed. He said this was redundant because it was specified in the Type information. Walter agreed and removed the sentence. Arpad asked Michael Mirmak to comment on "must" and "must not" vs "shall" and "shall not". Michael said that we use "shall" for rules we are defining. For things we don't directly control, for example, EDA tool behavior, we can say they "must". Based on this input, Walter changed one instance of "cannot" to "shall not" in the Usage Rules for Modulation_Levels. In the Usage Rules for PAM_Thresholds, Arpad said the following language was confusing: "The eye with the lowest voltage ..." Walter said it should say, "lowest threshold voltage". Radek, Arpad and others said the language describing the sequence of eyes with progressively higher threshold voltages should be improved. Ambrish asked why we needed the complication of using use Tables for these PAM parameters. Why couldn't they be defined as a simple String parameters whose values would contain a space delimited sequence of thresholds or offsets? Walter said he would send out a draft 12. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Arpad to submit BIRD211.4 to the Open Forum. AR: Walter to send out BIRD213.1 draft 12 incorporating today's changes. ------------- Next meeting: 15 February 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives